On Apr. 21, 2009, Bluetooth SIG (Special Interest Group) formally issued a new generation standard specification “Bluetooth Core Specification Version 3.0+High Speed”, which is referred to as “Bluetooth 3.0+HS” or “Bluetooth 3.0” for short. The core of the “Bluetooth 3.0+HS” is “Generic Alternate MAC/PHY” (abbreviated as AMP). As a completely new alternate radio frequency technology, the AMP allows Bluetooth protocol stacks to dynamically choose the correct radio frequency with regard to any task, and under the premise of being compatible with the original Bluetooth 2.1+EDR, a support for high speed transmission layer such as 802.11 (WiFi) and ECMA 368 (UWB) is added.
In an age of traditional Bluetooth controller, error correction and retransmission are handled by a Bluetooth controller terminal, a host terminal can guarantee the reliability of data transmission without making any special processing; according to the Bluetooth AMP infrastructure, however, the controller of a high speed transmission medium is no longer responsible for ensuring the reliability of data transmission, the host terminal needs to make an immediate error correction and retransmission mechanism, and the RT(ReTransmission)/FC(Flow Control) mode of the traditional Bluetooth L2CAP has a design defect: when a transmitting terminal detects a package loss, all non-response frames are retransmitted forcedly, moreover, only half of a transmission window can be used to transmit data at most. The “Bluetooth 3.0+HS” specification has defined an ERTM (Enhanced Retransmission)/SM (Steaming Mode) mode of eL2CAP and made an upgrade with regard to the design defect of the original RT(retransmission)/FC (flow control) mode, with main changes including: according to HDLC protocol subsets, a control frame of SREJ (selective reject)/RNR(receive not ready) is added; a bit field “Poll-Final” is added, when detecting a frame loss, a transmitting terminal firstly inquires the receiving terminal for the current receiving state via an “RR(Poll=1)” signaling, and then decides what kind of strategy will be used for retransmission, thus avoiding additional transmission expense brought by forced and continuous frame retransmission when detecting a frame loss under an RT mode, furthermore, the transmission of a full transmission window is realized, with the speed greatly improved compared with the transmission of maximum half of transmission window in the RT mode. The ERTM mode is still a sliding window transmission mode based on the transmission response.
During the process of data transmission between the transmitting terminal and receiving terminal, an Information frame (I frame) and a Supervisory frame (S frame) are included; the I frame which is used to transmit the upper layer protocol information and some control information (for example, flow control and error control) carries a transmit sequence number and receive sequence number; the S frame is dedicated to transmitting the control information of error control and flow control, and the S frame whose main functions are to request and hang up transmission, to report state information and to confirm the receipt of I frame only carries a receive sequence number. However, an ACK (Acknowledge) response is a transmission control character used for flow control, indicating a confirmation that one or more I frames transmitted from the transmitting terminal have been received faultlessly: once the transmitting terminal receives an ACK response from the receiving terminal, the transmitting terminal will transmit the next group of I frames to the receiving terminal; if the transmitting terminal receives no ACK response, then the transmitting terminal can re-transmit the current I frame, or stop the transmission of I frame. When the ACK response has an I frame to “take”, the ACK response is transmitted in a manner of I frame “carrying”; otherwise, the ACK response can only be transmitted by S frame, for example, said “RR(Poll=1)” signaling is an ACK response of S frame.
When using the ERTM transmission mode, upper layer protocols of some “request-response models”, such as A2MP protocol (Alternate MAC/PHY Manager Protocol), require the use of a transmission window (receiving window and transmitting window) with a width of 1. At this time, a conventional transmission logic is: the receiving terminal directly makes a active ACK response of S frames after receiving one of I frames so as to avoid a block phenomena that I frames cannot be transmitted to the receiving terminal because the transmitting window at the transmitting terminal is full (i.e. one of I frames has been transmitted but no ACK response is returned), thus making the transmitting terminal continue transmitting the next one of the I frames. In primary optimization, considering that I frames of the upper layer protocol in the “request-response model” can often “carry” the ACK response, the ERTM transmission layer needs to create a timer of ACK response (ACK-Timer) for monitoring whether the upper layer protocol transmits those I frames “carrying” ACK responses before the ACK-Timer times out, and in this manner the number of ACK responses of S frames is reduced and the rate of transmission is improved.
However, such model only takes into account the communication path of a unidirectional “request-response” model, since two sides of communication are symmetrical in data transmission, it is very possible that each side initiates one request to the other. Under such condition of competing transmission, the receiving windows and transmitting windows of both sides are full, resulting in that no new I frame is able to be transmitted to the opposite side before the time out of the ACK-Timer which allows the transmission of the ACK response of S frames, and that the ACK response of S frames cannot be transmitted to the opposite side until the ACK-Timer is time out so as to clear the transmission block condition of the opposite side (i.e., clearing “the local receiving window is full”). The aforesaid situation that both sides cannot transmit I frames before the ACK-Timer times out is referred to as an ACK interlock delay. In such cases, both sides have to wait for the ACK-Timer's time out to recover data transmission, thus reducing the efficiency of the link establishment or transmission.
Besides, in other transmission protocols without a limitation that the width of the receiving window is 1, situations of ACK interlock delay are also possible to occur. Once ACK interlock delays happen, the rate of the transmission or the link establishment will be unavoidably affected to some extent.